\chapter{Verlauf der Arbeit}\label{chap:Verlauf der Arbeit}
\section{Aufgetretene Probleme}\label{sec:probleme}
\subsection{Systemunterschiede}\label{sec:systemunterschiede}
Programmcode der einwandfrei kompiliert und sich auf dem Hostsystem fehlerfrei ausführen lässt kann auf dem Zielsystem dennoch zu Programmabstürzen führen. Offenbar ist uClinux und die uClibc sensibler was Unschönheiten in den Pointeroperationen anbelangt. Wir waren allerdings nicht in der Lage, genau zu eruieren, bei welchen Gegebenheiten diese Probleme auftreten können. Um sicherzugehen sollte nach einer Addition auf einen Pointer stets ein Cast erfolgen. Bei gewissen Funktionen aus Standardbibliotheken, welche in der gcc-Version selbständig Speicher allozieren, muss für die uClibc-Version vom Programmierer selbst Speicher alloziert werden (z.B. bei sprintf).

\subsection{GPIO}
\subsubsection{GPIO\_6}
Der GPIO\_6 Pin wird vom MT0V032 Treiber ''besetzt'' daher steht er als Out-Port nicht zur Verfügung.
Dieses Problem lässt sich allerdings beheben: \\
In der Datei \textit{uclinux-dist/linux-2.6.x/drivers/media/video/blackfin/mt9v032.c} muss auf der Zeile 90 der Eintrag \textit{\#define USE\_GPIO} auskommentiert werden.

\subsubsection{Pflags (GPIO) Treiber}
Die GPIOs können momentan nur aus dem Kernel-Space angesprochen werden. Für eine Verwendung aus dem User-Space muss ein pflags-Treiber eingebunden werden. Die für das LCV-Board verwendete uClinux-Version bietet einen solchen pflags-Treiber und ein zugehöriges Testprogramm an. Wir haben beide eingebunden und konnten das Testprogramm erfolgreich ausführen. Allerdings wird in diesem Testprogramm nur geprüft ob der Device geöffnet werden kann und nicht ob tatsächliche Werte gesetzt werden können. Wir haben die Ansteuerung der GPIO's nach uClinux-Vorbild in unser Framework integriert. Beim Testen mussten wir leider feststellen, dass das Schreiben auf die GPIOs keinen Effekt an der Hardware erzielt.
Ein Hardwarefehler ist aber auszuschliessen. Möglicherweise ist das Problem auf eine Diskrepanz bei der Portierung von uClinux auf das LCV-Board zurückzuführen. Bei einer früheren uClinux Version wurden die pflags über einen proc-Device eingebunden; nun sind diese direkt in \textit{/dev} verfügbar. \\
Da Live Sources verwendet wurden ist nicht sichergestellt, ob der Treiber zum Zeitpunkt der Portierung bereits einsatzfähig war. Als Lösung würde sich anbieten den Treiber des letzten oder nächsten Stable-Releases zu Verwenden.

\subsection{Modul CAM}
\subsubsection{Bildausschnitt holen (lcv\_capture\_region)}
Die Funktion um nur einen Bildausschnitt von der Kamera zu holen konnten wir leider nicht mehr implementieren. Die Schwierigkeit liegt darin, die Kamera über die Konfigurationsregister korrekt einzustellen. Leider scheint es einige Abhängigkeiten zu geben welche aus dem Register-Datenblatt nicht direkt ersichtlich sind.

\subsection{Hardware}
Zu Beginn der Projektarbeit gab es massive Probleme mit der Ethernetschnittstelle. Es traten immer wieder unerklärliche Verbindungsunterbrüche auf.
Es stellte sich heraus, dass offenbar ein ungewollter Kontakt zwischen Leitungen auf dem LCV-Print und dem metallischen Gehäuse stattfinden konnte. Das Problem konnte behoben werden, indem das LCV-Board ausserhalb des Gehäuses verwendet wird. Das Design von neueren Printversionen wurde bereits angepasst.

\section{Persönlicher Rückblick}
In diesem Abschnitt möchten wir unsere Arbeit Revue passieren lassen und das Erreichte kritisch beurteilen. 
Zu diesem Zweck werden die einzelnen Punkte der Aufgabenstellung reflektiert.

\subsubsection{Evaluation einer geeigneten Open-Source, plattformunabhängigen Entwicklungsumgebung}
Die Entscheidung Eclipse als IDE auszuwählen hat sich für uns als absolut positiv herausgestellt. Eclipse war allen Anforderungen gewachsen, welche uns während der Arbeit begegnet sind. Ausserdem verfügt es über ein weites Spektrum an Plugins welche das Entwickeln erleichtern. 

\subsubsection{Evaluation der benötigten Funktionalität unter Berücksichtigung einfacher Erweiterbarkeit}
Das Eruieren des Funktionsumfangs und der Anforderungen an das Projekt war nicht immer ganz einfach. Es gab wenige Vorgaben und viele Freiheiten. Die Auslotung der verschiedenen Wünsche und Möglichkeiten in den Gesprächen war sehr interessant. Allerdings hat es auch sehr viel Zeit in Anspruch genommen, daraus Spezifikationen zu erstellen, anzupassen und zu validieren. Schliesslich haben wir aber eine Lösung gefunden, von der wir glauben, dass sie allen Interessen gerecht wird. Das Design eines Frameworks auszuarbeiten war auf jeden Fall eine herausfordernde Aufgabe, welche uns sehr zugesagt hat.


\subsubsection{Implementation und Test der Entwicklungsumgebung}
Die Implementation an sich war nach der Ausarbeitung des Designs nur noch ein kleiner Teil des Projekts. Als viel schwieriger stellte sich das Verfügbarmachen der Systemfunktionalität auf Anwendungsebene (Userspace) heraus. Es setzte relativ viel Systemkenntnisse voraus, weshalb wir immer wieder tief in die sehr spezifische Matrie eintauchen mussten (Kernelkonfigurationen, Treiberanpassungen, Portierungen usw.). Am Ende haben wir aber viele wichtige Erkenntnisse gewonnen und werden von diesem Projekt einiges mitnehmen können.
Gerne hätten wir noch etwas mehr Bildverarbeitung betrieben, ein paar Filter implementiert und die Möglichkeiten der Kameraregister noch etwas weiter ausgelotet. 

\subsubsection{Entwurf und Implementation eines Tutorials zusammen mit einer Bedienungsanleitung für künftige Anwender}
Die Qualität der von uns erstellten Anleitungen und Tutorials ist von uns selbst natürlich schwer einschätzbar. Wir haben versucht, den zukünftigen Entwicklern einen robusten Einstieg in die LCV-Umgebung und -Programmierung zu ermöglichen. Wir hoffen, dass die Einarbeitungszeit und Startschwierigkeiten im Umgang mit dem LCV-Board damit künftig minimiert werden können. Für Kritik sind wir selbstverständlich offen und würden uns über ein Feedback freuen.
